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Mission: 

Robotics  Conversion  Kits 


•  Provide  scalable  autonomy  in  a  single  material  solution  agnostic  of 
platform. 

-  Autonomy  (A)  Kit 

»  Autonomous  Hardware  and  Sensors 

-  By-wire  (B)  Kit 

»  Vehicle  Specific  Devices  to  Retrofit  Current  Tactical 
Vehicles 

-  Common  Interfaces 

-  Common  Framework 

•  Scalable  and  flexible  to  address  multiple  task  such  as  convoys, 
security,  reconnaissance,  sustainment,  maneuver,  maneuver 
support. 

•  Utilize  Existing  Manned  Fleet  of  Vehicles 

-  Mobility 

»  Years  of  Automotive  Experience 

-  Leverage  Mature  and  Developed  Logistic  Support 

»  Training 
»  Maintenance 
»  Spare  Support 
»  ARFORGEN  Cycle 
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High  Level  Objectives 


•  Shorten  robotic  platform/  function  development 
time 

•  Enable  scalable  autonomous  feature/function 
capabilities 

•  Reduce  module  cost  and  investment  at  an 
enterprise  level 

-  Develop  a  set  of  common  electrical  hardware  and 
software  interface  requirements  for  most  combat  and 
tactical  vehicle  platforms 

-  Consistent  HW/SW  interfaces  and  serial  data 
implementations 

-  Develop/acquire  common  Autonomy  and  Sensing  Kit 
designs  to  reduce  engineering,  verification/  validation, 
and  sustainment  resources  required. 

-  At  a  minimum,  common  functionality  and  interfaces  are 
required.  What's  "inside  the  Black  Box"  can  be  vendor 
specific. 
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RDECOM 


Example  of  Notional 
“Kit”-  based  System 


A-Kit 


A-Kit  Level  N 


Sensor  N 


A-Kit  Level  3 


Sensor  5 


Sensor  4 


Sensor  3 


Sensor  2 


Sensor  1 


Sensor  0 


A-Kit  Level  2 


A-Kit  Level  1 


Tele-Operation 

Processing 


C-Kit 

IED  Detection 

Weapons 

Manipulators 

Other  Intelligence 

Comms 

Processing 

Backplane 

Comms 

Backplane 


Autonomous 

Comms 

Navigation 

Backplane 

Leader/Follower 

Comms 

Processing 

Backplane 

B-Kit 


Operator  Interface  (Warnings, 
Displays,  Inputs) 


CAN 


CAN 


Enable 

Other  Actuation 

CAN 

Safety 

Auxiliary  Vehicle 

Enable 

Functions 

CAN 

Safety 

Transmission 

Enable 

Actuation 

CAN 

Safety 

Steering 

Enable 

Actuation 

CAN 

Safety 

Enable 

Brake  Actuation 

CAN 

Safety 

Enable 

Throttle  Actuation 

CAN 

Safety  System 

Vehicle  Control  Unit 


CAN 


Pose  Estimation 


Inertial  Sensors 


GPS 


Wheel  Speed 
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Safety  Warning  Package 

Active  Safety  Package 
Tele-op  Package 

Semi-Auto  Package 
(CAST  type) 

Autonomous  Package 


Safety  Sensor  Kit  (Radar 
+  Camera) 

Safety  Sensor  Kit 

Tele-op  Kit  (Radio  + 
Camera) 

Safety  Sensor  Kit  + 
Tele-op  Kit 

Safety  Sensor  Kit  +  Tele¬ 
op  Kit  +  Autonomous  Kit 
(ANS  Lidar) 


none 

Driving  Actuation  Kit 
Driving  Actuation  Kit 

Driving  Actuation  Kit 

Driving  Actuation  Kit 
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rdecomJ*  Why  AMAS  Kit  approach? 


•  Meets  Congressional  &  Defense  Goal  for  Robotic 
Vehicles 

•  Increases  Warfighter  Capabilities 

-  Enables  more  capable  and  less  costly  systems 

•  Increases  Soldier  and  Civilian  Safety 

-  Provides  state-of-the  art  active  safety  functions  to 
legacy  platforms 

•  Shorten  robotic  platform/  function  development 
time 

-  Quickens  deployment  of  new,  high  value  systems 

-  RAMP,  SOURCE,  CAST,  and  other  vehicle  -based  robotic 
systems. 
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rdegom^  AM  AS  Near  Term  Activities 


•  Determine  Robotic  Feature  Levels  &  Kit  Partitioning* 

-  How  many  levels  of  A-Kit  required?  3-4-5? 

-  How  many  B-Kits  needed?  One  per  unique  platform? 

-  C-Kits  have  the  most  variation,  but  must  maintain  interface 
consistency. 

•  Determine  potential  XBW  conversion  alternatives 

-  Deep  dive  existing  Platforms:  LTV,  Stryker,  MTVR,915,  etc. 

•  Determine  Sensing  and  Computing  alternatives 

-  Perform  SWAP-C  &  Performance  analysis  for  system/ 
subsystems/components 

•  Develop  prioritized,  achievable  rollout  plan 

-  Develop  program  plans  to  implement  kit  development 

Market  Survey  (RFI)  for  A&B  Kits  will  be  sent  out  to  traditional 

DoD  OEMs  as  well  as  to  Automotive  Suppliers  -  push  for 

increased  COTS  at  lower  costs. 

*  Study  intended  to  be  presented  in  August  2011  at  GVSETS  Conference 
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•  "Massive"  Kit  level  reuse 

-  A-Kit  economies  of  scale  reduce  cost  and  investment  at 
the  enterprise  level 

-  B-Kit  systems  remain  somewhat  platform  dependent, 
but  there  may  be  common  components  across 
applications 

•  Deeper  engagement  by  concentrating  resources 
currently  scattered  across  multiple  approaches 

•  Shared  lessons  learned  and  best  practices 

-  Beginnings  of  a  subsystem  focus  &  SME  growth 

-  Document  learning  into  functional  requirements 

•  Commonization  of  similar  features  &  functions 
across  multiple  applications 

-  Basic  functions  used  as  building  blocks  for  new 
capabilities 

-  Faster,  more  reliable,  &  less  expensive  capability 
development  and  deployment 
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rdecomJf  Congressional  Language 

From  the  FY01  NDAA  (PL  106-398) 


Congressional  language  was  a  goal  not  a 
mandate 

“SEC.  220.  UNMANNED  ADVANCED  CAPABILITY  COMBAT  AIRCRAFT  AND  GROUND 
COMBAT  VEHICLES. 

(a)  Goal. --It  shall  be  a  goal  of  the  Armed  Forces  to  achieve  the  fielding  of  unmanned, 
remotely  controlled  technology  such  that 

(1)  by  2010,  one-third  of  the  aircraft  in  the  operational 
deep  strike  force  aircraft  fleet  are  unmanned;  and 

(2)  by  2015,  one-third  of  the  operational  ground  combat 
vehicles  are  unmanned.” 
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•  Depots 

-  Many  current  /  legacy  vehicles 
under-utilized 

-  Multi-service  PMs 

•  LSI'S 

-  Building  Systems  to  Specific 
Platforms 

-  Repeating  Work  Across  Platforms 

-  Working  Outside  Expertise 

•  Sensor  +  software  +  actuation 

•  Sub-contracting  (cost  increase) 

•  Tier  II  Venders 

-  Do  not  have  specific  metrics  to 
build  COTS  products  to 


June  1,  2011 


Convoy  Applicatio 


•  Employ  applique  based  systems,  broken  down  into  functional,  inter-operable  kits: 
•  A  -  Kit:  Sensor,  Autonomy  Software, 


Standardized  Inputs  &  Outputs 


and  Communications  Package 


•  B  -  Kit:  Platform  Actuation  Package  J 

•  Allows  one-time  development  of  a  platform-specific  B-Kit 

•  A-Kit  developers  build  outputs  to  this  interface 

•  Allows  easier  ORD  modification  with  PM  offices 

•  Allows  venders  to  focus  on  their  specific  expertise 

•  Allows  platform-agnostic  A-Kits  and 

•  Would  promote  vendor  competition  and  drive  down  costs 


AlflcM* PS011 
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Inter-Operable  Convoy 


Proposed  Programmatic  View 


•  Source  select  multiple  LSI’s  (2  minimum) 

•  Each  LSI  responsible  for  building  a  complete  system  (A,  B  &  C  kits) 

•  Kit  inter-operability  demonstrated  by  forcing  a  mixture  of  vendor  kits  on  various  platforms 


LSI  1 

LSI  2 

A-Kit  =  Vender  (1) 
[)  B-Kit  =  Vender  (1) 


A-Kit  =  Vender  (2) 
B-Kit  =  Vender  (2) 


A-Kit  =  Vender  (1) 
[)  B-Kit  =  Vender  (2) 


A-Kit  =  Vender  (2) 
B-Kit  =  Vender  (1) 


A-Kit  =  Vender  (2) 
[)  B-Kit  =  Vender  (2) 


A-Kit  =  Vender  (1) 
B-Kit  =  Vender  (1) 
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Inter-Operable  Convoy 


RDECOM 


Interoperability  and  Integration 


Be 


•  Integration  and  interoperability  with  existing  systems 

-  AMAS  Technology  design  is  kit-based  /  emphasis  on  COTS  hardware 

-  Minimize  impact  to  legacy  interfaces 

•  Redundant  communications  for  functionality  in  jamming  environments 

•  Dual  kit  interface  path:  Simple  Hardware  Unit  /  Graphical  user  Interface 

•  Functionality  within  operational  architecture 

-  Enhancement  to  current  CONOPS 

-  New  functionality  for  legacy  operation 

-  Maintenance  procedure  development  /  System  Training  Plan  (STRAP) 

•  Seek  compliance  with  COCOM  /  XM  /  Sponsor  guidance 

-  Interoperability  validation 

-  Operational  approval 


June  1 , 2011 
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RDECOM 


Top  Level  Capabilities 
&  Metrics 


Capability 

Tasks 

Metric 

Baseline 

Goal 

FOC  09-08 

Soldier  Support 

Operator  Interventions 

hours 

1  per  50  hours 

1  per  100  hours 

Joint  Land  Ops 

System  Operation  Range 

Distance  in  meters 

60  meters 

1 00  meters 

FOC  09-04 
Operational  Tempo 

Speed 

Kph 

40kph 

80kph 

Joint  Land  Ops 

Lateral  Accuracy 

centimeters  from  lead  path 

120cm 

80cm 

Battle  space 
Awareness 

Obstacle  Avoidance 

Size  in  cmA3 

1 000cm  A3 

500cmA3 

FOC  07-01 

Protect  personnel 

Situational  Awareness 

Sighting  increase  % 

Target  sighting 
increase  10% 

Target  sighting 
increase  20% 

FOC  07-01 

Protect  personnel 

Emergency  breaking 

Interventions  per  hour 

1 

0 

Emergency  breaking 

Collisions 

0 

0 

Tactical 

behaviors 

Multi-vehicle  capability 

Vehicles 

4 

20 

Collaborative 

Operations 

Leader  /  follower  swap 

Transition  time  in  seconds 

Less  than  30 
seconds 

Less  than  10 
seconds 

FOC  09-04 
Commonality 

Platform  independent  hardware 

%  of  total  hardware  cost 

70% 

85% 

FOC  09-01 
sustainability 

Kit  cost 

%  vehicle  cost 

25% 

15% 

June  1,  2011 
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RDECOM 


Overall  Draft  Demonstration  and 
Programmatic  Strategy 


lira 


-  FYll:  Planning  and 
Coordination  for 

•  Technical  Assessments 

-  Interface 

-  Compatibility 

•  Operational  Assessments 

-  Exercises/ Deployments 

-  Sustainment 

-  FY12: 

•  2nd  TD  and  OUA  #1 

•  1st  OUA  Report 

-  FY13: 

•  OUA  #2 

•  Final  Report  /  JCTD 
Completion 

•  Begin  CPD 

•  Submit  POM  funding 


Expected  Interim  Capability 

•Achieved  and  supports  EU 

•  Supports  transition  (PoR  TBD) 

•  Fitted  to  vehicle 

-  Stay  Behind,  or 

-  Return  to  Tech  Base 
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Draft  Transition  Strategy 


•  FY11-12 

•  FY11  :  draft  CDD,  JCTD  socialization 

•  FY12:  tech  demo,  1st  OUA  /  Finalize  CDD  approval 

•  FY13 

•  2nd  OUA 

•  JCTD  can  transition  to  RS-JPO 

•  FY14-16 

•  POM  Line  Establishment  against  AMAS  CDD 

•  Confirmation  of  platform  customers  (cut-in  dates  and  quantities) 

•  AMAS  JCTD  would  act  as  near-term  CDD  risk  reduction 

•  Could  help  solidify  CDD  resourcing 

•  Acts  as  pilot  Inter-operability  program 

•  AMAS  focuses  on  inter-operability  and  thus  is  platform  agnostic 

•  A  JCTD  of  this  type  should  not  interfere  with  existing  platform-specific  programs 

•  I.E.  MM-UGV  /  ARV-L 
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INTEROPERABILITY 
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Interoperability  Defined 


The  ability  of  software  or 
hardware  systems  or 
components  to  operate 
together  successfully  with 
minimal  effort  by  end  user. 
Further  attributed  with 
functional,  behavioral, 
lifecycle,  and  architectural 
scopes,  and,  therefore,  can 
be  delineated  in  terms  of 
control  and  can  be 
categorized  into  levels, 
types,  or  degrees  in 
application  programs. 
Facilitated  by  common  or 
standard  interfaces. 
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Why  Interoperability? 


•  To  provide  sustainable  and  repeatable  processes  and  capabilities  to 
support  the  current  and  future  Warfighter 

•  Leverage  technologies  and  capabilities  across  all  UGS  partner 
organizations 

•  Increased  Modular  payloads  across  multiple  platforms 

•  Enables  agile,  responsive  mission  realignment 

•  Enables  Air/Ground  coordination/collaboration 

•  Broadens  payload/mission  equipment  package  vendor  base 

•  Specifies  logical  architecture,  standards,  requirements,  and 
conformance  approach 

•  Offers  increased  capabilities  at  lower  life  cycle  costs 

•  Facilitates  common  control  of  multiple  robotic  systems 

•  Employed  by  robotic  Program  Managers 

-  Acquisition  of  future  ground  robotics  system  programs  of  record 

-  Upgrade  of  currently  fielded  systems 


“Interoperability  is  the  countermeasure  to  obsolescence”  -  LTC  Hatfield,  ARCIC 
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RDECOM 


interoperability  Capabilities 
Implementation  Thought 

Process 


•  If  common  messages  are  used  by  both  the  sender  and 
receiver  of  information,  then  interoperability  can  be 
achieved. 

•  Each  element  of  a  system  knows  what  messages  to 
expect. 

•  Each  element  of  a  system  knows  what  messages  to 
send. 


Incoming  Message 

ElementA 

Outgoing  Message  Incoming  Message 

Element  B 

Outgoing  Message 

System  element  exhibits 
some  behavior  when  it 
receives  a  given  message 
that  it  recognizes. 


System  element  exhibits 
some  behavior  when  it 
receives  a  given  message 
that  it  recognizes. 
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RDECOM 


interoperability  Capabilities 
Implementation  Thought 
Process  fcont.) 


•  We  need  to  specify  what  the  messages  are. 

•  Messages  themselves  become  the  interfaces. 

•  System  /  subsystem  developers  know  which  messages 
to  expect  coming  in. 

•  System  /  subsystem  developers  know  which  messages 
need  to  be  sent  by  their  elements. 

•  Processes  &  algorithms  within  the  "black  boxes"  use  the 
messages  &  remain  proprietary  and  invisible  to  others 


Incoming  Message 

OCU 

Outgoing  Message  Incoming  Message 

Platform 

Outgoing  Message 

Incoming  Message 


Outgoing  Message  Incoming  Message 


Incoming  Message 


Operator 


Outgoing  Message 


Outgoing  Message 
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interoperability  capabilities 
Implementation  Thought 
Process  fcont.) 


•  Additional  things  need  to  be  defined  to  1)  facilitate 
proper  delivery  of  messages  and  2)  enable  modularity: 

-  Physical  interfaces  (enabling  modularity,  as  well  as  adequate 
throughput  of  messages  &  power  for  messages  to  flow) 

-  Information  handling  techniques  &  protocols  (enabling  reliability 
of  message  delivery,  flow  control,  message  routing,  etc.) 

-  Human  understandable  messages  for  interaction  between  the 
operator  and  the  OCU 


TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


Interoperability  Overview  - 
Scope  &  Objectives 


Z ^ 1  \ _ 1 


•  Define  interoperability  standards  for  integration  across 
UGVs  leveraging  other  standards  work  to  the  greatest 
extent  possible 

-  Open  Architecture  &  Interfaces 

-  Common  Control  Standards 

-  Communications  Data  Links 

-  Modular  Payload  Interfaces 

-  Conformance  &  Validation  Criteria 

•  Interoperability  Profile  Version  0  (IOP  VO)  will  define 
baseline  capabilities 

-  Fundamental  system  capabilities  and  functionality  of 
fielded  systems 

-  Standard  message  sets  for  common  control  across 

_ nlatfnrms  laa  OFM  i  mini  ip  software  rnrlinn 


Tech  Base  and  User  Communities  of  Interest  are  Embedded 
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Industry/Gov't  Participation 


•  SAE  AS-4 
implementation  of  IOP 

•  Priority/Sequences 

•  Private  Messages 

•  Transport 

•  AS-4  Committee 

•  Interfaces 


Industry  Forum  -  15  June  2010 

-  Industry:  33  Companies  (52) 

-  Gov't:  13  Gov't  Agencies  (36) 

-  Total  Participants:  88 

Working  IPT  Structure 

-  5  WIPTs 

-  Led  by  RSJPO  and  TAl 

-  Aligned  with 
IOP  Framework 

-  Industry  and  Gov't 
Participation 

•  15+  Companies/ll  Gov't 

-  Rules  and  process 

-  Collaborative  Meetings 

IPT  Meetings  (Higher  Level  Bo 

-  Cross  Leveling  of  Information 

-  Baseline  and  Change  Control 


Architecture 
System  Functions 
Mission  threads 
Implementation 
Performance 
Latency 
Network 
Validation 


Senior  Level 

Governance 

Baseline 

Change 

Control 

Board 


Waveforms 

Frequencies 

COMSEC  & 

Encryption 

Radio  Configuration 

Data  Rates 

Latency 


Logical  Arch. 
Interface  Reqt’s 
Data  link 
Software 
C2 
WMI 

Performance 
Training 


•  Sensors 
Video 

Payload  Architecture 
Emitters,  Audio  &  Acoustic 
Message  Protocol 
Performance 
Actuators 


Voluntary  Participation  by  Industry 


Interoperability  IOP 
Framework 


> 

X  yy  \\  \ 


Overarching  IOP 


Mission 

Analysis 


SAE  JAUS 
Profiling 
Rules 


Private 

Transport 

Messages 


i  i 

i  i  i 


Payload  IOP 

Control  IOP 

Comms  IOP 

Legend 


Separately 

Profile 

Published 

Attachment 
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Common  Within 


Mission  Specific  Payload 


Power  Supply 


Actuator 


Navigational  Sensors 


Mobility  Platform 


Common  Across 


Operating  Software 


Common  Integrating  Software 


Common  Controller 


Communications 


Artificial  Intelligence 
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IOP  Adoption  in  Acquisition 

Process 


FY11 

FY12 

FY13 

FY14 

FY15 

▲ 

A 

Begin 

VO 

IOP  VO 

. 

M&S  Validation 

_ w 

Current  Fleet 
Capabilities 


Interoperability  Integration  into  Fielded  Fleet  as  Opportunities  Allow 


Begin 
IOP  VI 


A 


VI 

M&S  Validation 


ODD 

Validatioi 


A 


ODD 

Validation 


Program 
Schedules  are 
Examples 


Pre-Acquisitior  tivixi 
Pre-Acquisition  Activities 


Begin 
IOP  V2 


Program  A 


A 


V2 

M&S  Validation 


A 


Program  B 


ODD 

Validation 


KEY:  A.  IOP  Version  0  IOP  Version  1  IOP  Version  2 


Begin 

IOPV3 


Pre-Acquisition  Activities 

▲ 

V3 


Test  activities 


A 


Future  Program  X 
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Recent  Activities 


•  16-17  Nov  2010  -  Government  /  Industry  WIPT  Kick-Off 

•  Jan-Feb  2011  -  Development  of  draft  IOP  VO  Capability 
Plan 

•  Feb  2011  -  Establishment  of  WIPT  Working  Groups 

•  09  Feb  2011  -  Interoperability  Synch  with 
Navy/AEODRS 

•  15  Feb  2011  -  JAUS  Profiling  WIPT  Meeting 

•  03  Mar  2011  -  Communications  WIPT  Meeting 

•  10  Mar  2011  -  Payloads  WIPT  Meeting 

•  30  Mar  2011  -  Overarching  WIPT  Meeting 

•  07  April  2011  -  Control  WIPT  Meeting 
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Established  Working  Groups  in 

WIPTs 


Overarching 

•  Test  &  Validation 

•  Sys  Eng  &  Architecture  (TBD) 

•  Latency  (TBD) 

Communications  •  Radio  Link  •  RFI  Mitigation 

•  Physical/Power  Interface  •  Security 

•  Logical  Interface 


JAUS  Profiling 

•  Platform  Manager 

•  Capability  Plan 

Compliance 

•  ID  Assignment 

•  Autonomy/Behaviors 

•  Access  Control 

•  Digital  Video  Stream 

•  Sensors  Message 
Implementation 

•  Radio  Status 
Messages 

Payloads 

•  Existing  Standards 

•  Logical  Interface  / 

Metadata 

•  Physical  Interface 

•  Configuration  /  Taxonomy 

Control 

•  Discovery 
•OCU 

•  Human  /  Machine  Interface 

IOP  VO  Capability  Plan 


VO  Capability  Plan  has  been  drafted 
Scopes  &  bounds  what  IOP  VO  will  define 

Focused  on  foundational  capabilities  inherent  in 
currently  fielded  syJ 


UGV  Interoperability  Profile  (IOP) 
Capabilities  Plan 


Robotic  Systems.  Joint  Project  Office  (RS  JPO) 
SFAE-GCS-UGV  MS  266 
6501  East  11  Mile  Road 
Warren.  Ml  48397 
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IOP  VO  Capability  Plan  Content 


•  3.1  Platform/Vehicle 

-  Electrical,  Mechanical,  &  Power 

-  Basic  Platform 

•  Battery  Status,  Usage  &  Engine  Data 

•  Platform  Mode 

•  Position  /  Attitude 

•  Sub-System  Configuration  &  Health 

•  Pose  /  Articulation 

•  E-Stop  &  Heartbeat  (Liveness) 
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IOP  VO  Capability  Plan  Content 

(cont.) 


3.1  Platform/Vehicle 

-  Mobility  (Basic) 

•  Drive  Mode 

•  Gear 

•  Speed  /  Acceleration 

•  Speed  /  Acceleration  Limits 

•  Steering 

•  Brake 
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IOP  VO  Capability  Plan  Content 

(cont.) 


3.1  Platform/Vehicle 

-  Mobility  (Advanced) 

•  Drive  Sensor  Registration  &  Selection 

•  Drive  Timeout 

•  Create/Insert/Delete  Waypoint  /  Waypoint  List 

•  Load  &  Execute  Waypoint  Plan 

•  Waypoint  Following  Status 

•  Suspend/Resume  Waypoint  Following 

•  Leader/Follower  Mode  &  Attributes 

•  Execute  Leader/Follower  Operation 

•  Following  Status 

•  Suspend/Resume  Waypoint  Leader/Follower 
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IOP  VO  Capability  Plan  Content 

(cont.) 


3.2  Payload 

-  Sensor 

•  Drive  Vision 

•  Motion  Imagery 

•  Still  Imagery 

•  CBRN 

•  Chemical  Explosive  Detection 

•  Microphone 

•  Range  Finder 

•  Thermal 
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IOP  VO  Capability  Plan  Content 

(cont.) 


3.2  Payload 

-  Emitter 

•  Lights 

•  Speaker 

-  Actuator 

•  General  Actuators 

•  Basic  Arm 

•  Telescoping  (Mast) 

•  Pan/Tilt 

•  End  Affectors 
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IOP  VO  Capability  Plan  Content 

(cont.) 


3.3  Communications 

-  Radio  Link 

-  Radio  Subsystem  Interface 

-  Radio  Frequency  Interference  (RFI)  Mitigation 

-  Radio  Status  Health 

-  Wireless  Security 
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IOP  VO  Capability  Plan  Content 

(cont.) 


3.4  Control 

-  Human  Controller  Interface  (HCI) 

•  Battery  Status  Display  Interface 

•  Radio  Setup  and  Comms  Link  Monitoring 

•  Robotic  Asset  Selection,  Login  &  Controls 

•  Common  Icons  &  Graphics 

•  Basic  Status  Display 

•  Warnings,  Cautions  &  Alerts 

•  State  and  Mode  Selection 

•  Input  Device  Mapping 

•  Video  Window 

•  Image/Video  Archive  &  Browsing 

-  Mission  Planning 

•  Mission  Plan  Metadata  and  Graphics 
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/ 


Draft  VO  Implementation 
Concepts 


Slides  develop  as  a  communication  tool  for  what  needs 
to  be  defined  for  IOP  VO 

Includes  concepts  &  ideas  for  specific  "instantiations"  of 
what  VO  capabilities  require  in  terms  of  messages  & 
interfaces 


IOP  VO  Capability 
Implementation  Concepts 

Mark  Mazzara,  Systems  EngineeringTeam  Lead 
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Implementation  Concept 
Example:  Battery  Status 


•  Battery  Status: 


Define  Requirements:  Overarching  WIPT 
Define  Messages:  JAUS  Profiling  WIPT 


-  Description:  Percentage  of  battery  power  or  hours  of  battery 
operation  remaining 


-  Action:  Display  a  message  on  the  OCU  that  provides  the  battery 
state  of  charge.  May  be  a  graphical  display,  a  percentage,  or  a 
summary  of  expected  remaining  minutes  of  operation. 

-  VO  Deliverable: 


•  Message  structure  &  format 

-  Query  Battery  Status 

-  Report  Battery  Status 


OCU 


Open  Questions: 

•  Format  as 
percentage? 

•  Format  as  remaining 
minutes? 

•  Define  timing 
requirements? 


What  is  battery  status? 


Battery 

Battery  status  is  X 

\ 

Other 

Elements 

S 

\ 

‘Conceptual  Example 
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RDECOM 


implementation  concept 
Example:  Drive  Sensor 
Registration 


Define  Requirements:  Payloads  WIPT 
Define  Messages:  JAUS  Profiling  WIPT 

Steering: 

-  Description:  Specifies  sensor  used  to  drive  the  platform  (if 
multiple  -  e.g.,  forward,  reverse) 

-  Action:  Report  the  available  drive  sensors.  Report  current  drive 
sensor.  Set  drive  sensors. 

VO  Deliverable: 

•  Message  structure  &  format 

-  Query  Current  Drive  Sensor 

-  Report  Current  Drive  Sensor 

-  Set  Drive  Sensor 

-  Query  Available  Drive  Sensors 

-  Report  Available  Drive  Sensors 


Open  Questions: 
•Correlate  this  message 
to  Drive  Mode  or  other 
messages? 

•  Define  logical 
description  of  drive 
sensors  in  messages? 
•Define  timing 
requirements? 


Platform 

Element 


I  am  using  drive  sensor  X. 


I  have  drive  sensors  X,  Y, 
and  Z  available. 


What  drive  sensor 
are  you  using  now? 


Use  X  drive  sensor. 


What  other  drive 
sensors  do  you  have? 


"Conceptual  Example 


TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


RDECOM 


Implementation  Concept 
Example:  Wireless  Security 


Se 


•  Wireless  Security: 

-  Description: 

•  Establish  a  secure  wireless  communications  link 

-  Action: 

•  Determine  available  encryption  schema  and  turn  on/off  encryption 

-  VO  Deliverable: 

•  Message  structure  &  format 

-  Query/Report  Available  Encryption  Schema 

-  Set  Encryption  (Type  X,  Type  Y,  off,  etc.) 


Define  Requirements:  Communications  WIPT 
Define  Messages:  JAUS  Profiling  WIPT 
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Path  Forward  Toward  IOP  VO 

Completion 


•  Continue  regular  WIPT  telecons  &  execution  of  WIPT 
deliverables 

•  Develop  matrix  mapping  VO  capabilities  with  existing 
standards  messages,  interfaces  &  protocols 

-  Identify  gaps  in  existing  standards 

-  Compare  trades  of  different  standards/messages  that  achieve 
similar  capabilities 

•  Select  /  develop  IOP  VO  standards/messages  with 
WIPTs 

•  Document  proposed  IOPs 

•  Staff  proposed  IOPs  through  WIPTs  &  JPO  chain  for 
approval 

•  Target  September  2011  for  VO  Publish 


TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


Path  Forward  Toward  IOP  VO 

Completion 


•  Continue  regular  WIPT  telecons  &  execution  of  WIPT 
deliverables 

•  Develop  matrix  mapping  VO  capabilities  with  existing 
standards  messages,  interfaces  &  protocols 

-  Identify  gaps  in  existing  standards 

-  Compare  trades  of  different  standards/messages  that  achieve 
similar  capabilities 

•  Select  /  develop  IOP  VO  standards/messages  with 
WIPTs 

•  Document  proposed  IOPs 

•  Staff  proposed  IOPs  through  WIPTs  &  JPO  chain  for 
approval 

•  Target  September  2011  for  VO  Publish 
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RDECOM 


nmanned  Ground  Vehicle 
Interoperability 


Challenge:  Begin  to  address  the  Multi-National  requirement  in 
the  Unmanned  Systems  Initial  Capabilities  Document. 
Objective:  Use  the  Robotic  Systems  Joint  Project  Office  (RS 
JPO)  interoperability  Profile  (IOP)  in  a  operationally  relevant 
Coalition  experiment/assessment. 

Deliverables:  1 .  Software  subsystems  and  modifications  will  be 
provided  to  TRADOC  and/or  RS  JPO  upon  request. 

2.  Subject  Matter  Experts  who  worked  on  this  program  will  be 
available  for  TRADOC/RS  JPO  if  needed  for  further  assistance. 

3.  Reports  on  the  performance  of  OCU(s),  platforms,  radios  and 
payloads  to  perform  relevant  tasks. 

4.  Improvements  rolled  into  the  RS  JPO  IOP  Version  1  and  2. 

5.  Joint  CONOPS  and  TTPs  will  be  leveraged  by  TRADOC. 
Technology  Maturity:  TRL  level  7  projected  at  completion  of  CWP 
Capabilities  Shortfalls  Addressed:  Interoperability  Profile  for  one 

Coalition  partner  can  be  used  by  another  partner  allowing  for 
flexibility  in  Coalition  level  missions 


US/Canada  Prototypes 
COTS  Hardware 
OCU  Software 


RS  JPO  Interoperability  Profile  VO 


Financial  Information 

($) 

MILESTONE  (FY) 

12 

13 

CWP  Year  One  (FY12): 

$ 

Integrate  OCU  on  Hardware  Platform 

Develop  software  on  TARDEC  Robot  using  IOP  vO 

CWP  Year  Two  (FY13): 

$ 

$ 

Other  US  Financial  Contributions: 

Develop  software  on  Canadian  robot  using  IOP  vO 

US  Non-Financial  Contributions: 

$ 

Integration  and  Test  Both  UGV 

Foreign  Financial  Contributions: 

$ 

Foreign  Non-Financial 

$ 

Relevant  Demonstration  (Robotics  Rodeo/AEWE) 

Contributions: 

Final  Report 

▲ 

Total  Project: 

$ 

A 

POC:  Paul  Bounker,  TARDEC  CWP  Nomination  for  FY1 2-1 3  M)LOGY  DRIVEN.  WARFIGHTER  FOCUSED. 

586  282-5297,  paul.bounker@us.army.mil  Annex  C 


